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STS PAYLOADS MISSION CONTROL STUDY 


STUDY OBJECTIVES 


These are the basic objectives of the Study. They have remained unchanged. 
In the process of meeting these Study objectives, information, was developed for 
use by NASA in arriving at STS Payload flight c.ontrol activity allocations to 
NASA Centers. Seven basic Study tasks are described in the following pages 
“which produce documentation to meet these objectives, i.e.: flight control 

functions, NASA flight control capabilities, function allocations, operational 
communications and information processing plans, alternative system concepts for 
STS Payload flight control support and estimated additional resources for 
selected system cbncept(s). 
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SJS PAYLOADS MISSION. CO.NTROL STUDY 


STUDY OBJECTIVES 


0 IDENTIFY FLIGHT CONTROL GROUND FUNCTIONS FOR REPRESENTATIVE STS PAYLOADS ■; ; 
. (REQUIREMENTS) AND NASA CAPABILITIES TO. SUPPORT THEM. 

t DETERMINE FEASIBLE, COSt EFFECTIVE .SYSTEM CONFIGURATION OPTIONS FOR .FLIGHT 
CONTROL OF STS PAYLOADS. .. 

• . ESTIMATE ADDITIONAL NASA RESOURCES REQUIRED, IF ANY, TO IMPLEMENT NASA- 
. SELECTED OPTION(S). ■ - . 
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STUDY TASKS 


The Study- consist's of the seven basic tasks listed. The Ancillary Task, "Identification of User 
Enhancement Factors", is included with Task f. Each of these tasks typically consists of three or 
four subtasks. For example. Task c consists of Subtask c.l, "Establish Categories of Capabilities 
Information Needed", followed by Subtask c. 2, "Conduct Interviews and Follow-up with Key Personnel". 

Finally, the information obtained is documented in a "NASA Capabilities Document" (separate volume for 
each NASA Center), Subtask c.3, and coordinated with contributors prior to publication. 

These tasks may be considered as being accomplished in three major phases of activity. Task a,, 
b and c constitute the first phase, the Data Collection Phase. The second phase, primarily a "Systems 
Engineering and Analysis" type phase consists of Tasks d, e and f. It begins with the allocation of 
flight control ground functions between the STS Operator and Payload Operator while operational infor- 
mation flow and processing plans are being developed, and culminates in the identification of viable 
system concept options for allocation of payload flight control activities among NASA Centers.- In the 
last phase. Task g, a methodology is established for' estimating resource requirements for system concept 
option(s) selected by NASA and actual estimates made of any additional resources required to 
carry out the chosen option(s). 

Task b objectives have been enhanced to include identification of candidate facility utilization 
concepts to be examined in more detail later under Task f. Also, the establishing of operational interfaces, 
formerly part of Task d, has been shifted to Task e, and analysis of Task d results has been included 
in Task f. 


1-3 



STUDY TASKS 


a. IDENTIFY FLIGHT CONTROL FUNCTIONS AND ALLOCATE ONBOARD/GROUND. 

b. IDENTIFY GENERIC TYPES AND LOCATIONS OF PARTIES INVOLVED. AND 
CANDIDATE FACILITY UTILIZATION CONCEPTS. 

C. ESTABLISH PRESENT/PLANNED NASA-WIDE FACILITIES CAPABILITIES. 


d. ALLOCATE FUNCTIONS BETWEEN STS OPERATOR AND PAYLOAD OPERATOR. 

e. ESTABLISH OPERATIONAL INTERFACES, INFORMATION FLOW AND DATA PROCESSING PLANS. 

f. DEFINE ALTERNATIVE SYSTEM CONCEPTS. 


g. ESTABLISH RESOURCES METHODOLOGY AND ESTIMATE ADDITIONAL RESOURCES FOR SELECTED 
SYSTEM CONCEPT(S). 
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STUDY SCHEDULE 


The Study consists of the three major' activity phases as shov/n on the schedule, culminating in 
completion of the Final Report after 10 months. The Final Report consists of 15 volumes published 
incrementally throughout the Study, including the Executive Summary Report (Volume I) at the end of 
the Study, plus a separately bound document for each Task and a separately bound document for the 
facility capabilities at each NASA Center visited under Task c. Nine months of this 10-month Study 
are completed. Phase I, the Data Collection Phase, was extended an additional two months to allow 
for including extensive unforeseen additional inputs to the Center Capabilities Documents provided 
after initial contacts and after release of Preliminary Draft versions of the documents. 

The Phase II activities leading to selection of a preferred system concept have been completed. 
Ground function allocations and operational -communications and data flow information have been docu- 
mented as Task d and e reports, respectively. In Task f, the first-step was to define System Con- 
cept selection criteria and coordinate these with the COR. Alternative system concepts were then 
developed for assessment against these criteria. NASA has selected the preferred concept for quanti- 
tative assessment by the Study Team of additional resources required. The last Task, g, is in-process 
and will be documented in time for delivery with the Summary Report. 

Each of the four Study Reviews shown on the schedule has been followed by a review with the NASA 
Steering Committee for STS Paylo.ad Operations Concept Studies. 
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STUDY SCHEDULE 


1975 


NASA 


' ACTIVITY 

AUTHORITY TO PROCEED 
■PERFORMANCE REVIEWS ■' ' ' 

FINAL SUMMARY REPORT 

PHASE I. -DATA COLLECTION 

9 PAYLOADS/FLiGHT TYPES 

• FLIGHT- CONTROL FUNCTIONS 

• FACILITY UTILIZ; CANDIDATES 

• NASA CAPABILITIES ~ 

.PHASE -I I,. SYSTEM CONCEPTS 

• FUNCTION ALLOCATIONS 

t OPERATIONAL COMMUNICATIONS 
AND DATA FLOW 

• SYSTEM ENHANCEMENTS 

V CONCEPT 'SELECT CRITERIA 

• SYSTEM CONCEPT OPTIONS 

PHASE III. RESO.URCES ESTIMATES 
'• RESOURCES MODEL , ■ • 

• RESOURCES ESTIMATES 



INTERFACE 


REVIEW 


REVIEW 


PROVIDED 

REVIEWED 

REVIEWED 

INPUTS 


REVIEWED 
& APPROVED 


APPROVED 
■.SELEGJED . . 



LEGEND: 


\7 SCHEDULEDi 


COMPLETED: 




CONTROLLED MILESTONE; 


] TO BE DONE; COMPLETED; F7Z^ 77 7) 
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EXTENDED 
























STUDY GUIDELINES 

The General Study Guidelines have remained unchanged with. exception of the Flight Traffic Model, 
Guideline 19,. which was updated by the COR-'as of 4 June' 1975. Detailed statement of each-general 
guideline follows: 

1. The STS, consisting of the Shuttle, lUS/TUG andSpacelab support systems, with flight 
control from MCC/JSC, provides .a. service to "customers". ["Customers" here are all NASA 
Centers and selected non -NASA/non -DOD payloads that utilize NASA Centers for flight opera-’ 
tions. (DOD payloads are not included in this study.)] 

2. The main thrust of this study effort will address STS payload programs during the opera-', 
tional STS phase. 

3. The existing NASA capabilities, resources and modus operandi will be used as points of 
departure i n . perf ormi ng this study. 

4. For automated payloads, flight control capability will be concentrated on the ground to 
the maximum extent. 

* , i 

5. Flight support shall be provided in a manner which satisfies the requirements at minimum 

; overall expenditure of resources. ■ ' 

6. Flight support must be responsive to onboard assistance, for problem resolution and 
activity planning, but may be "on-^11" rather than instantly responsive. "On-call" 
means having expertise arid systems available, but not dedicated to flight support. 
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STUDY GUIDELINES 


1. STS PROVIDES SERVICE TO "CUSTOMERS" 

2. STUDY ADDRESSES STS PAYLOADS DURING OPERATIONAL STS PHASE 

3. EXISTING NASA CAPABILITIES POINT OF DEPARTURE FOR THIS STUDY 

4. GROUND CAPABILITY PRIMARILY CONSIDERED FOR AUTO PAYLOADS 

5. PROVIDE FLIGHT SUPPORT WITH MINIMUM EXPENDITURE OF RESOURCES 

6. FLIGHT SUPPORT TO PROVIDE ONBOARD AID "ON CALL" INSTEAD OF INSTANTLY 
RESPONSIVE. 
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.STUDY GUIDELINES (CONTINUED) 


7. Flight support shall be interactive, i.e., able to effect mission changes which maximize the 

mission value. - . - 

8. Payload operations will be performed by a payload organization or its agent within safety limits 
established by the STS Operator. 

9. MCC/JSC will provide "flight support"' for all NASA missions during prelaunch, ascent, reentry and 

landing. ("Flight support" here includes: - GO/NO-GO for launch 

- -Traaectory, Event, Systems, Crew Status 

- Landing site readiness.) 

10. For on-orbit operations during periods when STS has an operational interface with the payload, 
"flight support" will be jointly provided' by MCC/JSC and the responsible Payload Operations Center. 
[‘"Flight support" here includes all functions (tasks) done in support of the on-orbit operations.] 

11. For on-orbit operations during periods when the STS has no operational interface with the payload, 
"flight support" will be provided by the responsible Payload Operations Center or Agent designated 
by the responsible payload project office, 

12. Payload organizations will utilize NASA Control Center host facilities for payload operations or 
establish their own Payload Operations Centers where economically justified. 
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STUDY GUIDELINES (CONTINUED) 

7. FLIGHT SUPPORT IS INTERACTIVE TO MAXIMIZE MISSION RETURNS 

8. PAYLOAD OPERATIONS SAFETY- LIMITS UNDER COGNIZANCE OF STS OPERATOR 

9. MCC GIVES FLIGHT SUPPORT DURING PRELAUNCH, ASCENT, REENTRY, AND LANDING 

10. RESPONSIBILITY OF JOINT OPERATION OF STS AND PAYLOAD SHARED BY MCC AND- 
THE POC 

11. POC FULL RESPONSIBILITY FOR ITS PAYLOAD DURING FREE-FLI6HT 

12. USERS UTILIZE NASA HOST FACILITIES OR ESTABLISH OWN POC 
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STUDY GUIDELINES (CONTINUED) 


13. Major NASA Control Centers shall provide host facilities for customers, or provide appropriate 
operational interfaces with customers' remote location with respect to the Control Center, if 
feasible. 

14. Required voice, data, command and .tracking .channels 'wil 1 be provided to all operations areas, but 
coordinated by MCC/JSC so long as STS has an operational interface. 

15. ■ Automation (computerized tools) should be employed by POC's if needed to meet flight requirements 

or if consistent with reducing operations costs. 

16. Detailed "flight planning" for payloads is responsibility of the payload developer and the Payload 
Operations Center. Detailed flight planning for the Shuttle and integration of the flight plan 
definition for STS and STS payloads operation’s is the responsibility of JSC. ["Flight planning" is 
the generation of detailed procedures and timelines for nominal and contingency execution of flight 
activities.] ' 

17. A semi -automated "flight data base" shall be assumed. The "flight data base" need not be in one 
location so long as means for adequate transfer and interfacing of information between operations 
centers is provided. 

["Flight data base" is the reservoir of all data needed to plan or execute a .flight, including 
system specification values, models, operating constraints, schedules, etc.] 

18. Simplicity of interfaces during launch/landing and during flight among user, developer and 
operator, and ease of total STS/STS payload ground system verification shall be considered 
as criteria in assessing interfaces and costs. 

19. The study will use the Flight Traffic Model provided by the COR on 4 June 1975. 
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STUDY GUIDELINES (CONTINUED) 


13. NASA CONTROL CENTERS PROVIDE HOST FACILITIES OR OPERATIONAL INTERFACES 
WITH CUSTOMERS. 

14. DURING STS/PAYLOAD OPERATION, VOICE, DATA, COMMAND & TRACKING CHANNELS 
COORDINATED BY MCC/JSC. 

15. AUTOMATION IN POC IS DESIRABLE TO REDUCE COSTS. 

16. PAYLOAD "FLIGHT PLANNING" BY PAYLOAD ORGANIZATION - STS/PAYLOAD INTEGRATED 

FLIGHT PLANNING BY JSC. • 

17. DISBURSED SEMI-AUTOMATIC "FLIGHT DATA BASE" ASSUME. 

18. INTERFACE SIMPLICITY AMONG USER, DEVELOPER, AND OPERATOR AND EASE OF SYSTEM 
VERIFICATION IS CRITERIA. 

19. WILL USE UPDATED TRAFFIC MODEL PROVIDED BY THE COR, 4 JUNE 1975. 
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TASK a 

FLIGHT CONTROL GROUND FUNCTIONS 


The objective of Task a was to identify flight control functions for given STS Payloads and 
Flight Types and allocate those functions between onboard and ground as a basis for further alloca- 
tion of the ground functions between STS Operator and Payload Operator in Task d. 

In order to complete this Task a objective, the first step was to identify and document payloads 
and flight types to be addressed by the Study Team. These were established by NASA and supplied via 
the COR to the Study Team along with current Flight Traffic Model for inclusion in Study documenta- 
tion and analysis. 

The Study Team then described characteristics of the payloads pertinent to flight control such 
as flight description, inflight handling - deployment/retrieval/servicing, potential STS interface, 
potential hazards such as in-flight contamination, and where known, experiment characteristics and 
Center assignment{s) for operations. 

The major challenge in Task a was to identify flight control functions, such as verify ephemeris, 
monitor payload systems, compute consumables remaining, etc., that must be performed for each cargo 
flight type and applicable flight phase. 

Finally, these flight control functions were allocated to Onboard (0), Ground (G), or Both Onboard 
and Ground (B), in Task a as a prelude to the special allocation. of the "Ground" functions to STS 
Operator or Payload Operation or some combination of STS Operator/Payload Operator in Task d. 
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TASK a 

FLIGHT CONTROL GROUND FUNCTIONS 


OBJECTIVE: 


SUMMARY OF 
TASK RESULTS: 


IDENTIFY FLIGHT CONTROL GROUND FUNCTIONS FOR GIVEN STS PAYLOAD 
FLIGHT TYPES AND ALLOCATE ONBOARD/GROUND. 


9 REPRESENTATIVE PAYLOAD FLIGHT TYPES WHICH WERE ADDRESSED BY 
THE STUDY WERE ESTABLISHED BY NASA AND DOCUMENTED BY STUDY TEAM. 

® DESCRIPTIONS AND CHARACTERISTICS OF SELECTED PAYLOADS PERTINENT TO 
FLIGHT CONTROL DOCUMENTED. 

» FLIGHT CONTROL FUNCTIONS FOR EACH PAYLOAD IDENTIFIED AND DOCU- 
MENTED BY APPLICABLE FLIGHT PHASES. 

0 FLIGHT CONTROL FUNCTIONS ALLOCATED (1) ONBOARD, (2) GROUND OR 
(3) BOTH ONBOARD AND GROUND. . • ' • ■ . 



TASKb 

TYPES AND LOCATIONS OF PARTIES INVOLVED 

The main objectives of Task b were to characterize and describe the NASA Payload Development 
Centers as to their experience in and readiness .or. suitability. for involvement in payload flight 
control operations, and to evaluate candidate facility utilization concepts for assignment of pay- 
load flight control roles. 

Seven NASA Centers were visited and their characteristics for payload flight control documented ' 
with respect to the 14 flight types and 21 individual payloads under study. 

With these NASA Center characteristics for payload flight control fresh in mind, three prelimi- 
nary facility utilization concepts were defined and assessed based on appropriate involvement of 
the applicable Centers, in three payload flight type categories — automated earth orbit, planetary 
and spacelab. The three candidate concepts assessed as a precursor to Task f were; (1) complete 
centralization — one NASA Center for each flight type category, (2) partial decentralization, i.e., 
two or three NASA Centers per flight type category, and (3) complete decentralization, each Center 
responsible for flight control of its own payloads. 

The concept assessment technique included both qualitative and quantitative techniques and 
flight traffic impact assessment. All techniques applied were useful as a basis for the criteria 
and approaches finally used in Task f. 



OBJECTIVE: 


SUMMARY 
OF TASK 
RESULTS : 


TASKb 

TYPES AND LOCATIONS OF PARTIES INVOLVED 

CHARACTERIZE NASA PAYLOAD DEVELOPMENT CENTERS FOR FLIGHT 

CONTROL OPERATIONS AND EVALUATE CANDIDATE FACILITY UTILIZATION 

CONCEPTS. 

fl DETERMINED NASA CENTERS' INVOLVEMENT IN PAYLOAD DEVELOPMENT 
AND MISSION OPERATIONS AND DOCUMENTED FINDINGS BY CENTER 
AND FLIGHT TYPE. 

c IDENTIFIED PRELIMINARY FACILITY UTILIZATION CONCEPTS FOR 
PAYLOAD FLIGHT CONTROL (RANGING FROM CENTRALIZED TO 
DECENTRALIZED) AS PRECURSOR TO TASK f. 

e ESTABLISHED AND APPLIED PRELIMINARY APPROACH TO ASSESSMENT 
OF ALTERNATIVE CONCEPTS. DEVELOPED TECHNIQUES APPLICABLE IN 
TASK f. 
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TASKc 

PRESENT/PLANNED NASA-WIDE CAPABILITIES 


The objective of Task c was to define each NASA Center's present and planned capabilities 
for flight control of STS payloads at the system level. 

The Study Team first established guidelines and agendas for data collection and communicated 
these to NASA Center contacts provided at each Center by the COR. Guidelines included such 
information as level of detail (system level), extent of equipment identification (mainly functional), 
and guideline for "planned" capabilities (must be in approval cycle). These guidelines, along with 
functional categories for Data Collection and summary of results from the seven Centers visited 
are summarized in a Task c general document. 

The seven Centers visited are as shown on the chart. Facilities/capabilities have been 
documented separately for each Center biit in consistent format. The seven functional categories 
of information shown provided the consistent outline for the appendices and were carefully 
selected to provide information needed in Tasks e and f. These functional categories are 
defined in the General Task c document. 
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OBJECTIVE: 


SUMMARY OF 
TASK RESULTS: 


TASKc 

PRESENT/PLANNED NASA:W!DE CAPABILITIES 

EVALUATE AND DOCUMENT NASA-WIDE PRESENT AMD PLANNED FACILITIES/ 
CAPABILITIES FOR FLIGHT CONTROL OF STS PAYLOADS AT SYSTEM LEVEL. 

0 GUIDELINES FOR DATA COLLECTION AND ASSESSMENT ESTABLISHED. 

t SEVEN NASA CENTERS VISITED AND DATA ON THEIR CAPABILITIES DOCUMENTED 

APPENDIX A - ARC APPENDIX D - JSC 

APPENDIX B - GSFC APPENDIX E - KSC 

APPENDIX C - JPL APPENDIX F - LaRC 

APPENDIX G - MSFC 

• GENERAL DOCUMENT DEFINES GUIDELINES, FUNCTIONAL CATEGORIES FOR 
DATA COLLECTION AND SUMMARIZED RESULTS. 

• SEVEN FUNCTIONAL CATEGORIES DOCUMENTED FOR EACH CENTER 

- GENERAL PAYLOAD INVOLVEMENT, OPERATIONAL MODES 

- CONTROL CENTER AND/OR MONITORING CAPABILITIES 

- TRACKING AND DATA ACQUISITION CAPABILITIES 

- COMMUNICATIONS AND DATA HANDLING CAPABILITIES 

- COMPUTATION AND DATA MANAGEMENT CAPABILITIES 

- PAYLOAD TRAINING AND SIMULATION CAPABILITIES 

- PAYLOAD HOST FACILITIES 


c-2 



TASKd 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

• , ‘ * t i * \ • ' ' 

The objective of Task d was to define payload associated flight control ground functions 
required for each, flight phase of given payload flight types and to allocate responsibility 
for those functions to the Payload Operator or STS Operator or both. Some functions were 
assigned to both Operators jointly or to one Operator monitored by the other. 

The steps leading up to this allocation of functions included identification of applicable 
flight phases, developing guidelines for allocations, identification of the flight control 
ground functions (with input from Task a) and, finally, allocation to one of the five categories 
shown on the chart. These steps and summary of results are presented in subsequent charts. 
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TASKd 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS . 


OBJECTIVE: 


SUMMARY 
OF TASK 
RESULTS: 


DEVELOP ALLOCATION OF PAYLOAD FLIGHT CONTROL GROUND FUNCTIONS 
BETWEEN THE PAYLOAD OPERATOR AND STS OPERATOR. 

c ESTABLISHED THE FLIGHT PHASES APPLICABLE TO THE 14 GIVEN 
FLIGHT TYPES. 

• THE 15 UNIQUE FLIGHT PHASES IDENTIFIED WERE CORRELATED 
WITH THE FLIGHT TYPES TO DETERMINE EXTENT OF FUNCTION 
REPEATABILITY. 

• GENERAL GUIDELINES DEVELOPED FOR ALLOCATION OF THE FLIGHT 
CONTROL GROUND FUNCTIONS. 

• GROUND FLIGHT CONTROL FUNCTIONS IDENTIFIED AND NUMBERED 
FOR EACH FLIGHT TYPE/PAYLOAD AND FLIGHT PHASE. ' 

• EACH OF THE 666 FLIGHT CONTROL GROUND FUNCTIONS 
ALLOCATED (X) TO ONE OF THE FOLLOWING FIVE CATEGORIES: 

- PAYLOAD OPERATOR 

- PAYLOAD OPERATOR WITH STS OPERATOR COGNIZANCE (MONITOR) 

- PAYLOAD OPERATOR AND STS OPERATOR 

- STS OPERATOR WITH PAYLOAD OPERATOR COGNIZANCE (MONITOR) 

- STS OPERATOR 



TASKd 

FLIGHT TYPES AND REPRESENTATIVE PAYLOADS 


This chart summarizes the payloads associated with each of the 14 flight types 
addressed by the study. These 14 fli.ght types further break down into the three major 
categories, Automated Earth Orbit, Automated Planetary, and Spacelab, as shown. 
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OF POOR QUALiry 


TASKd 

FLIGHT TYPES AND REPRESENTATIVE PAYLOADS 


CATEGORY 

FLIGHT TYPE 

REPRESENTATIVE PAYLOADS 

AUTOMATED 

*LEO DELIVERY (E) 

EARTH OBSERVATIONS SATELLITE (EOS) 

EARTH ORBIT 

LEO DELIVERY AND 
RETRIEVAL IF) 

LARGE SPACE TELESCOPE (LST) 
DELIVERY AND HIGH ENERGY ASTRO- ■ 
PHYSICS OBSERVATORY RETRIEVAL 


LEO REVISIT/SERVICE 
W/O EVA (G) 

EOS 


LEO REVISIT/SERVrCE 
W/EVA (H) 

LST 


LEO MULTICARGO 
DELIVERY (I) 

BIOMEDICAL EXPERIMENTAL SCIENTI- 
FIC SATELLITE (BESS), 2-MINI-LAGEOS , 
AND FREE-FLYER TELEOPERATOR 


LEO MULTICARGO POLAR 
ORBIT, SPACELAB AND 2 
DELIVERIES TO LEO (J) 

LIFE SCIENCES (SPACELAB MODULE), 
SPACE TEST PROGRAM (DOD), AND 
EXPLORER 


lUS MULTISATELLITE 
DELIVERY (K) 

DISASTER WARNING SATELLITE (DWS), 
NOAA, AND FOREIGN COMMUNICATIONS 
SATELLITE (FCS) 


TUG MULTISATELLITE 
DELIVERY (M) 

TRAFFIC MANAGEMENT SATELLITE 
(TMS), FAA, AND INTERNATIONAL 
COMMUNICATIONS SATELLITE (INTEL/ 
SAT) 

AUTOMATED 

PLANETARY 

'lUS PLANETARY (L) 
TUG PLANETARY (N) 

MARINER 

PIONEER 

SPACELAB 

MODULE AND PALLET. 
DEDICATED (A) 

ADVANCED TECHNOLOGY LABORATORY 
(ATL) 


MODULE AND PALLET, 
MULTIDISCIPLINE (B) 

**ATMOSPHERIC MAGNETOSPHERIC PLASMAS- 
IN-SPACE (AMPS) AND SPACE PRO- 
CESSING (SP) 


PALLET ONLY, 
DEDICATED (C) 

SOLAR PHYSICS (SO) 


PALLET ONLY, MULTI- 
DISCIPLINE (D) 

SO, STANDARD EARTH OBSERVATIONS 
PACKAGE FOR SHUTTLE (SEOPS), AND 
HIGH ENERGY ASTROPHYSICS (HEA) 


*LE0 = LOW EARTH ORBIT AND (E) REFERS TO FLIGHT TYPE IDENTIFIER IN 
TABLE 1.5-1. 

**PARTIAL PAYLOADS APPROPRIATE IN THIS COMBINED CONFIGURATION. 
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TASKd 

FLIGHT PHASE CODE 


Fifteen flight phases were identified as being applicable to the 14 flight types 
assigned for this study. Two major categories of orbital vehicle configuration were 
addressed in designating these flight phases - one when the payload or payload/IUS/TUG 
are attached to the Orbiter, and the other when the payload or payioad/IUS/TU6 are 
separated from the Orbiter. 



TASKd 

eight phase code 


1 . ORBITER-ASCENT 

2. ORBITER. ON-ORBIT PAYLOAD ACTIVATION/CHECKOUT 

3. ORBITER-PAYLOAD DEPLOYMENT 

4. ORBITER ON-ORBIT PAYLOAD OPERATIONS 

5. ORBITER-PAYLOAD RETRIEVAL 

6. ORBITER-PAYLOAD SERVICING 

7. ORBITER-PAYLOAD DEACTIVATION 

*8. ORBITER-TUG/PAYLOAD DEPLOYMENT 
*9. TUG-ASCENT TO PARKING ORBIT 

*10. TUG ON-ORBIT ACTIVATION/CHECKOUT 
*11. TUG-PAYLOAD DEPLOYMENT/INJECTION 
*12. TUG ON-ORBIT PAYLOAD OPERATIONS 
*13. TUG- RETURN ORBIT 

*14. ORBITER-TUG/PAYLOAD RETRIEVAL 
15. ORBITER RE-ENTRY AND LANDING 


*IUS WILL BE USED IN LIEU OF TUG INITIALLY 
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TASKd 

CORRELATION OF STUDY FLIGHT TYPES AND FLIGHT PHASES 


This chart shows the correlation of .flight phases with the flight types identified 
in this study. It will be noted that only two flight phases, ORBITER-ASCENT and 
ORBITER-ON ORBIT PAYLOAD ACTIVATION AND CHECKOUT, are common to all flight types. The 
Orbiter re-entry and landing flight phase is addressed only when a cargo is aboard at 
landing. Several of the phases are unique to only a few flight types such as revisit/ 
servicing flights, as shown. . . ■ , 

There were 88 total flight phases addressed individually over the 14 flight types, 
or an average of approximately six flight phases per flight type. 
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TASK d. 

CORRELATION OF STUDY FLIGHT TYPES AND FLIGHT PHASES 
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f TA$l< d 

GENERAL GUIDELINES FOR GROUND FUNCTION ALLOCATION 


This chart identifies the general guidelines used in allocating the flight • 
control ground functions to one of the, function assignee categories. In cases where 
. allocation of functions was not completely clear-cut, the allocation was generally 
made toward greater Payload Operator responsibility then STS Operator. 

It should be noted that both the Payload Operator and the STS Operator are 
involved in three of the five categories and that each has some responsibility in 
four of the five categories, ' 
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TASKd 


GENERAL GUIDELINES FOR GROUND FUNCTION ALLOCATION: 


FUNCTION ASSIGNEE 

APPLICABLE GUIDELINES 

PAYLOAD 

OPERATOR 

• PAYLOAD FUNCTIONS WHILE IN FREEFLYING MODE (NOT ATTACHED TO ORBITER OR lUS/TUG) 
0 NON-HAZARDOUS PAYLOAD EXPERIMENTS FUNCTIONS (PAYLOAD ATTACHED TO STS ELEMENT) 

■0 PAYLOAD/SUPPORT FUNCTIONS NOT REQUIRING STS 

PAYLOAD OPERATOR 
W/STS OPERATOR 
COGNIZANCE 

0 PAYLOAD EXPERIMENT FUNCTIONS INVOLVING POTENTIAL HAZARD TO STS' 
e PAYLOAD FUNCTION UTILIZES STS CONSUMABLES 
0 PAYLOAD FUNCTION IMPACTS STS TIMELINES 
0 CRITICAL PAYLOAD FUNCTIONS MONITORING 
0 GO/NO-GO FOR- CONTINUING FLIGHT 
0 PAYLOAD EXPERIMENT FAULT ANALYSIS 

PAYLOAD OPERATOR 
AND STS OPERATOR 

0 HANDOVER FUNCTIONS BETWEEN STS-PAYLOAD OPERATORS 

0 OTHER FUNCTIONS INVOLVING JOINT STS-PAYLOAD OPERATOR ACTIVITY 

0 FUNCTIONS THAT MUST BE PERFORMED BY BOTH STS AND PAYLOAD OPERATORS 
(CONSUMABLES MANAGEMENT) 

STS OPERATOR 
W/PAYLOAD OPERATOR 
COGNIZANCE 

0 STS SUBSYSTEMS OPERATIONS THAT SUPPORT OR SERVICE PAYLOAD OPERATIONS, SUCH AS 
TRAJECTORY POSITIONING AND POINTING 

0 STS OPERATOR FUNCTIONS REQUIRING SUPPORT OF PAYLOAD OPERATOR, SUCH AS VERIFI- 
CATION OF THE CENTER COMMUNICATIONS INTERFACES 

STS OPERATOR 

0 POWERED FLIGHT 
0 SAFETY MONITORING 

0 SERVICE FUNCTIONS TO PAYLOAD OPERATOR, SUCH AS CARGO BAY ENVIRONMENT MONITORING, 
VERIFYING ORBITER-PAYLOAD CONNECTIONS, ETC. 

0 STANDARD (REPETITIVE) SERVICE FUNCTIONS, SUCH AS DATA TRANSMISSIONS 

0 STS FUNCTIONS REQUIRED TO EFFECT REQUIRED CONDITIONS FOR PAYLOAD OPERATIONS 
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TASK d 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

The following five charts were extracted from the Final Report, Volume II-D, to provide 
examples of the flight control ground functions considered in the Study and to show how 
Operator assignments were identified. 

Each function is uniquely identifiable by Flight Type - Flight Phase - Function Number; 
for example. Function A-1-3 uniquely identifies the function, MAINTAIN TEMPERATURE OF BIOLOGICAL 
REFRIGERATOR, and the prefix "A-1" indicates the function is included in Flight Type "A", 

Flight Phase "I", which are "Spacelab Module and Pallet, Dedicated" and "Orbiter-Ascent" , 
respectively . 



TASKd 


, ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

FLIGHT TYPE: A SPACELAB MODULE AND PALLET, DEDICATED 

PAYLOAD: ADVANCED TECHNOLOGY LABORATORY (ATL) 

FLIGHT PHASE; 1 ORB ITER-ASCENT 
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STS OPERATOR WITH 
PAYLOAD OPERATOR 
COGNIZANCE 









TASKd 


ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 


Sample allocations continued. 



TASKd 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

FUGHT TYPE: A SPACELAB MODULE AND PALLET, DEDICATED 

PAYLOAD: ADVANCED TECHNOLOGY LABORATORY (ATL) 

FUGHT PHASE: 2 ORBITER ON-ORBIT PAYLOAD ACTIVATION AND CHECKOUT 


OPERATOR 

assignment 


FUNCTION 


1. MONITOR PAYLOAD TELEMETRY; VERIFY CRITICAL FUNCTIONS WITHIN 
OPERATING LIMITS 

2. VERIFY PAYLOAD PYROTECHNICS NOT ARMED 

3. VERIFY ORBITER BAY TEMPERATURE, PRESSURE, CLEANLINESS 
ENVIRONMENT WITHIN LIMITS REQUIRED BY ATL 

4. VERIFY OPERATION OF ALL ORBITER SUBSYSTEMS WHICH SUPPORT 
THE ATL 

5. STIMULATE ATL COMMAND SYSTEM; VERIFY FUNCTIONAL STATUS 

6. SET UP, CALIBRATE AND CHECKOUT PAYLOAD INSTRUMENTS AND 
EQUIPMENT 

7. DEPLOY BOOM AND ESTABLISH INITIAL POINTING 

8. IF REQUIRED, PARTICIPATE WITH CREW IN FAULT ANALYSIS AND 
ISOLATION 

9. INPUT VEHICLE ORIENTATION PARAMETERS FOR ATL 
TO. DETERMINE GO/NO-60 FOR CONTINUING FLIGHT 
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TASKd 


ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 


Sample allocations continued. 
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TASKd 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

FLIGHT TYPE: A SPACELAB MODULE AND PAlLeT, DEDICATED 

PAYLOAD: ADVANCED TECHNOLOGY LABORATORY (ATL) 
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TASKd 


ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 


Sample allocations continued. 



TASKd 


ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

FLIGHT TYPE: a SPACELAB MODULE AND PALLET. DEDICATED 

PAYLOAD: ADVANCED TECHNOLOGY LABORATORY (ATL) 

FLIGHT PHASE; 7 ORBITER-PAYLOAD DEACTIVATION 


OPERATOR 

ASSIGNMENT 


FUNCTION 


1. MONITOR PAYLOAD TELEMETRY; VERIFY SYSTEMS STATUS FOR 
RE-ENTRY 

2. VERIFY DEACTIVATION OF ALL ORBITER SUBSYSTEMS NO LONGER 
REQUIRED TO SUPPORT ATL 
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TASK d 

ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 


Sample allocations continued. ' 



TASKd 


FLIGHT TYPE; 
PAYLOAD; 
FLIGHT PHASE; 


ALLOCATION OF FLIGHT CONTROL GROUND FUNCTIONS 

A SPACELAB MODULE AND PALLET, DEDICATED 
ADVANCED TECHNOLOGY LABORATORY (ATL) 

15 ORBITER RE-ENTRY AND LANDING 
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STS OPERATOR WITH 
.PAYLOAD OPERATOR 
COGNIZANCE 








TASKe 


OPERATIONAL INFORAAATION FLOW 
AND PROCESSING 


The objective for Task e was to develop a model and methodology to deter- 
mine the operational flight control information flow and operational data 
processing required to implement the flight control task with the operational 
interfaces. 

The methodology and model were generated which describe the approach to 
derive the communications and operational data processing information require- 
ments at the major interfaces between the key elements of the STS payload ground 
network. 

Flight control data base capabilities and plans for each site were reviewed. 
The requirements for a Supervisory Data Base Management System were recommended. 

The system enhancement requirements for a baseline system concept were deter- 
mined based on using GSFC, JPL, and JSC as the primary Payload Flight Control 
Centers for automated earth orbit, planetary and Spacelab payloads, respectively . 
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TASKe 


OBJECTIVE: 


SUMMARY OF 
TASK RESULTS: 


OPERATIONAL INFORIVIATION FLOW 
AND PROCESSING 


DEVELOP A MODEL AND METHODOLOGY TO IDENTIFY 
COMMUNICATIONS CHANNELS AND DATA PROCESSING 
REQUIREMENTS BETWEEN STS PAYLOAD FLIGHT CONTROL 
ELEMENTS. 


I METHODOLOGY AND MODEL FOR DERIVING COMMUNICATION 
AND DATA PROCESSING TRAFFIC LEVELS - 

% RECOMMENDATIONS FOR A SUPERVISORY DATA BASE 
SYSTEM FOR STS RAYLOAD FLIGHT CONTROL 

• ■ SYSTEM ENHANCEMENT REQUIREMENTS FOR BASELINE 
SYSTEM CONCEPT 



TASKe 


SEQUENTIAL FLOW OF MODEL GENERATION 

The objective of this effort was to identify the communications channels and transfer 
functions between team members and system elements of the STS Payload operational system. 

This was accomplished by generating a model along with establishing the methodology 
such that when implemented with a computer program, meaningful data can be derived. 

The Sequential Flow of Model Generation depicts the methodology for applying the model 
(this technique was presented in detail at the Midterm Progress Review). 

1. SSPD Documents - Used as primary source for specific Payload data. 

2. Payload Data Summary Worksheets (Per P/L) - Provides Forward/ Re turn Link data for 

Prelaunch C/O, P/L Deployment from Orbiter, I US and Tug, and P/L Operational 
Phases for each Payload. 

3. Payload Data Summary Worksheets (Per P/L Flight Type) - Accumulates data for each P/L 

from 2. into worsT casedata per Flight Type. 

2 

4. N Charts - Establishes operational interfaces (nodes) between the primary functional 

Payload centers for each phase and P/L type. 

5. Payload Simultaneous Operations Charts - Provides quantity of each Payload Flight 

type bperatinq at the same time. 

6. Payload Flights/Year Traffic Model - Provides quantity of flights per Payload type 

per year. 

2 

7. Total Summary N Nodes - Presents the node totals for all representative flight types 

and phases. 

2 

8. Summary N Nodes Per Year - Depicts same info as 7. per year plus the number of launches 

and overlap operations per year. 

Node Summary - Provides a summary of the total data for a specific interface node 
during a year. 


e-3 



TASKe 

SEQUENTIAL FLOW OF MODEL GENERATION 











. TASK e 


CONCLUSIONS FROM COMMUNICATION 
AND DATA FLOW ANALYSIS 


Three sample Payload Flight Types were evaluated using the methodology 
and model for communication and data flow analysis; Space] ab - Dedicated 
Module & Pallet (A), Low Earth Orbit - Single Cargo - Delivery (E), and 
Planetary - lUS (L). 

From information derived from the SSPD Documents, it was' determined 
that only one of the study representati ve payloads exceeded T1 communication 
circuit bandwidth: EOS-20,0 Mb/s. 

In order to thoroughly evaluate the complete interface (Node) require- 
ments, the Methodology and Model, should be implemented into a software 
program. Since this model solves for Worst Case conditions, it is .recommended 
that the model also be expanded to incorporate the Most Probable operational 
overlap conditions. 
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TASKe 


CONCLUSIONS FROM COMMUNICATION 
AND DATA FLOW ANALYSIS 


• THREE SAMPLE CASES WERE TESTED WITH THE MODEL 

9 ONLY ONE PAYLOAO WITH VERY HIGH DATA RATE IDENTIFIED 

9 NEED FOR SOFTWARE MECHANIZATION OF MODEL AND REDUCTION -TO 

"MOST PROBABLE" IN ADDITION TO "WORST CASE" 
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TASKe 


DATA BASE APPLICATIONS CHART 


The Data Bases required are qross data base categories identified as the major categories 
for Payload Operations. 

In addition to indicating the Data Base Participants associated with each type of data base, 
the chart depicts approximations of 3 types of processing: 

Query Rates - Frequency Data Base is exercised 

Update Requirement - Frequency Data Base is modified 

Active Historical Span - Time Data Base is stored in normal access mode. 

The Data Bases required are: 

1. Control of DB System (Directory) - Complete definition and instructions for use of all 

STS and PL Data Bases. 

2. Pl/User DB - Payload experiment data required only by the PI. 

3. SSPD Data Base - SSPD desiqn and operation data for each PL. 

4. Universal Document System DB - Library of both manual and computerized storage, 

divided into STS and Payload data categories. 

5. Interface Control Documents DB - ICD's for PL/Orbiter, PL/Spacelab, PL/Tug or lUS, 

and PL/Launch and Landing Facility. 

6. Communication Tracking System - Includes acquisition and control data, orbit 

determination, and maneuvering data. 
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TASKe 

DATA BASE APPLICATIONS 



A£ AirrOhATEO EARTK ORBIT 
AP AinrOHATED PLAHrARY 


OURINQ PAYLOAD 
OPERATIONAL PHASE 


S - SHARED 0»B. 


X • USER (COMMON ACCESS) 
0- HOST D B. 


' NON^HASA PAYLOADS OHLY 
* INFREQUENT: <\0 ACCESSES PER DAY 
MODERATE lO-IDO ACCESSES PER DAY 
FREQUENT >>100 ACCESSES PER DAY 


I** M INFREQUENT 
H** » MODERATE 


II** • FREQUENT 


H « 2 TO 10 YEARS 
M - UP TO 2 YEARS 


L * MONTHLY OR LESS 
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TASKe 


DATA BASE APPLICATIONS CHART (CONTINUED) 


7. Master Measurements Data Base r PL/STS measurements deri ved .from all testing and' 

accumulated telemetry data. Used for troubleshooting and fault isolation. 

8. Problem Reporting and Corrective Action DB - Test Data to support the detection, 

fault isolation, and correction of STS/PL and PL. peculiar operations. 

9. Launch/Landing Process System DB - Payload launch and landing support data including 

test and checkout data. , 

t 

\ " * 

10. Payload Peculiar DB - Generated and maintained at the POC includes PL operation and 
experiment (data. 

n. Telemetry and Data Accounting System Data Base - PL housekeeping trend analysis 
control and predictions, orbital and tracking data, etc. 

■ c 

12.. Scientific Experiment DB Categories - 12 through 23 on the chart are defined in 
Task "a" and the SSPD Documents. . 
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TASKe 


DATA BASE APPLICATIONS CHART (CONTINUED) 


(Same as previous chart) 



TASK e 

STS/PAYLOAD DATA BASE INTERFACE CONCEPT 


This chart depicts a centralized/distributive method by which the STS/Payload Data Bases 
could be interfaced. 

The Data Base interfaces at GSFC, JPL, and JSC are shown with the user and NASA common 
data. ARC is shown as an overlapping function to indicate that its payload operations will 
probably receive data base support from JPL. MCC-H is shown as an overlapping function with 
JSC because of its probable utilization of JSC data base facilities. Also, MCC-H will share 
STS characteristics and constraints data base information with the payload world. 

KSC and VAFB each will possibly provide launch and landing data base support. VAFB is 
shown as an overlapping function with KSC to indicate the duplication of the types of data 
bases. 

MSFC will provide the SSPD Data Base and the Payload Traffic Model Data Base information. 

The Payload Development Centers wi-11 possibly provide payload peculiar data base informa- 
tion including test data to support Payload operational maintenance and troubleshooting. 

The STC data base interface will probably be primarily with the MCC-H for its operational 
functions. 
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TASK e 


STS/PAYLOAD DATA BASE INTERFACE CONCEPT 
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TASKe 


TYPICAL POC FUNCTIONAL FLOW 


POCC FUNCTIONS (Inner Circle) 

1. Experiment Monitor and Control - Strip and format data for processing, provides data to 

Mission Ops and Control Center, evaluate raw data, tronitor status of data. Quick Look 
process. In Depth data evaluation, and generate operational data. 

2. Command and Control Processing - Generate commands, verification, monitor command operations, 

and maintain command logs. 

3. Telemetry Input Processing - Receive data and reformat if required, decommutate data, 

process and output data, and generate displays’ for telemetry data. 

4. Attitude Data Processing - Strip and output attitude da'ta to the Central Facility, and 

. monitor data quality . ■ ■ ' • 

• ' 5i' Operations and Control - Direct PL operations and control, responsibility for PL command and 
control , execute PL plans, evaluate and control PL activities ,' and plan - control - and 
•evaluate ground support activities. ' • , ■ 

6. Flight Planning and Control - Evaluation of PL system, coordinates PI support and PL health 
• . requirements, and technical evaluation of total PL/ground support system. 

CENTRAL FACILITY PROCESSING FUNCTIONS 

1. Orbit Determination - - 

2. Flight Maneuver Computations 

3. Attitude Computations 

4. Payload Control Processing 

5. Experiment Data Processing 

6. Data Base Management, Storage, and Retrieval 
SPECIAL PURPOSE COMPUTATION ALTERNATIVES 

1. PI may bring mini -computer and software to POCC. 

2. Integrate user requirements into institutional computing capability at NASA Center. 

3. Host facility may implement user requirements into existing operational capability. 

4. User requirements may be integrated through use of a portable remote POCC at the users location. 
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TASKe 

JSC PAYLOAD OPERATIONS CENTER CONCEPT 

. ^ . *1 
i ' , 

This chart depicts the recominended Spacelab POC system concept. 

The POC Elements are; ^ 

1. POCC Clusters - Based on past exp'erience and planned capabilities, the POCC Cluster 

Types at JSC will consist of: Earth Resources, Life Science's, Astronomy, 

Science and Technology, and Multi disciplines. 

2. Data Communications Subnet - A network of interface processors which provide for 

interconnecting the clusters, the large scale computers and the NASCOM Interface 
Processor. 

3. Storage System - The Data Base Management system including mass storage and retrieval 

of data base information. 

4. Large Scale Computer Support - Use of the Central Computer Facility to provide off line 

support to the POCC's. Support consists of experiment processing and payload 
attitude and orbit determination. 

5. -Information Processing Support - Use of the RTCC Facility to provide real/time and near 

reaiytime support for PL telemetry and experiment processing. 

A Typical POCC consists of: 

1. VIP (Virtually Interfaced Peripherals) - A minicomputer that interfaces peripheral 

. devices (CRT terminals, printers, etc.) to the communications subnet. It provides 
•both virtual and real mapping functions for its peripheral. 

2. PIP (POCCNET Interface Processor) - A minicomputer that provides for the POCC 

interface with the remainder of the Center's Facilities, 

3. TIP (Telemetry Input Processor) - Minicomputer which receives and processes all tele- 

metry signals addressed to its associated POCC. 

4. CCAP (Control Center Applications Processor) - A medium scale computer which supports 

telemetry conversion, provides command processing and supports the control and 
monitor consoles and displays. 
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JSC PAYLOAD OPERATIONS CENTER CONCEPT 

^ \ / ASTRONOMY \ . ' 

X I SPACELABPOCC \ X c^icKirp ak 
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: y MSK e 

GSFC PAYllOAD 0‘PERATIONS'CENTER CONCEPT 

This chart .depicts the .panned GSFC. POCCNET concept. 

Based on past experience and planned capabilities, the POCC Cluster -types of GSFC would consist 
of: Free Flyer Multi -Satellite, Solar and Atmospheric Physics Satellites, Earth Observations 

Satellites, Stellar Astronomy Satellites, andSpacelab Payloads. 

■ . The Large Scale Computer Support could be provided by the planned, IBM 360-65, 360-75, and 360-95 

systems . 

I 

The Information Processing Support could be provided by the Central Data Processing Facility 
and the Image' Data Processing Facility. 
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TASKe 

GSFC PAYLOAD OPERATIONS CENTER CONCEPT 



NASCOM 



TASKe 


JPL PAYLOAD OPERATIONS CENTER CONCEPT 


This chart depicts a JPL Planetary POC concept. 

Based on past experience and planned capabilities, the POCC types at JPL would include: 
Mariner, Viking, Venus, and HELIOS. 

Pioneer, Life Sciences and Astronomy POCC's can be located at ARC, operating as a remote 
facility in coordination with JPL. 

Large Scale Computer and Information Processing Support would use the Mission Control and 
Computing Center (MCCC) and the General Purpose Computing Facility (GPCF). 
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JPL PAYLOAl) OPERATIONS CENTER CONCEPT 
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TA.SKe 


IMPLEMENTATION PHASING 


System enhancements discussed under Task e are recommended for implementation under the 
phasing schedule for Task f implementation which is shown on the adjacent page. 

Phase I extends from the present time through 1980. Major activities during this phase 
are .to complete the definition of system requirements for an evolutionary NASA-wide system 
for STS payload support and to complete the implementation for the Phase II system. 

Phase II covers the period from 1980 to 1983 and will be termed the "baseline system". 
This is the initial three center capability for STS payload support. During this phase, 
implementation for Phase III must be completed. 

Phase III extends from 1983 to 1986 and is termed the "transition phase"; not to be 
confused with the STS transition phase. This is the period of transition from the baseline ' 
capability to the "all-up" systems capability for STS payload support. Implementation for 
Phase IV must be completed during this phase. 

Phase IV is the fully operational phase and the ultimate system configuration should be 
ready at the beginning of this phase. During this phase STS payloads will operate in a fully 
integrated NASA-wide STS payload support system which utilizes standard POCC's and standard 
procedures to the extent practical. 
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TASK e 

implementation phasing 


• SYSTEM ENHANCEMENTS MENTIONED IN TASK e ARE INCLUDED' IN TASK f IMPLEMENTATION' PHASING. ‘ • 
PHASE DEFINITIONS ARE AS FOLLOWS: 


PHASE 

!■ 

■■ 1976-1980 
REQUIREMENTS 
DEFINITION 

■COMPLETE REQUIREMENTS DEFINITION FOR ALL-UP SYSTEM. 
COMPLETE IMPLEMENTATION FOR PHASE II SYSTEM'; 

PHASE 

II 

1980-1983 

BASELINE 

SYSTEM 

AUGMENTED EXISTING CAPABILITY. IMPLEMENTATION FOR 
PHASE III. 

PHASE 

III 

' 1983-1986 ■ 

■ TRANSITION 
PHASE 

BUILD TOWARD FULL CAPABILITY. IMPLEMENTATION FOR 
PHASE TV. 

PHASE 

IV 

1986-1991 

FULLY 

OPERATIONAL 

FULLY INTEGRATED NASA-WIDE STS PAYLOAD SUPPORT- SYSTEM. 
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TASK,e 

JSC SPACELAB PAYLOAD OPERATIONS CENTER 

enhancement REQU I remEnts 

The basic .approach in the establishment .of the Enhancement Requirements for the JSC 

Spacelab POC is based on: , . • 

1. POCCNET approach planned at the GSFC. The POCC plans by JPL are similar to 
the POCCNET plan. 

2. At least during the Phase I period and possibly during Phase II, it should 
be planned to use the existing computer facilities as well as existing 
experiment, Skylab, and ASTP facilities. This provides a baseline for later 
facility expansion. 

3. The past experience and existing capabilities of JSC make it the logical 
choice for recommendation as the Spacelab POC. Earth Resource, Life Science 
and Manned Spacecraft capabilities presently exist at JSC. 

The schedule for development of the POC facilities is: 

1. Phase I (1976 thru 1979) - Full support to the OFT program and all associated 
payloads. Expand POC capability as practicable; use STS facilities which are available. 

2. Phase II (1980 thru mid 1983) - Expand the POCC facilities to meet the flight 
requi rements. 
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JASK e . 


JSC SPACElj\B PAYLOAD OPERATIONS CENTER 
ENHANCEMENT REQUIREMENTS- 

BASIC APPROACH 

• BASED ON POC PLANS FOR GSFC & JPL 

• USE EXISTING CAPABILITIES 
0 PAST EXPERIENCE 

SCHEDULE 

• 1976 THRU 1979 : PHASE I, IMPLEMENTATION FOR PHASE II 

• 1980 THRU MID 1983 ; PHASE II (BASELINE SYSTEM) 
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TASKe 


SUMMARY OF ENHANCEMENT REQUIREMENTS 

The following are the recommended system enhancements which should be considered for the 
Payload Operational Phases III, and IV. (mid-1983 through 1991): 

1. Baseline NASA Payload Centers ' ■ 

Automated Earth Orbit - GSFC 

Space! ab - JSC 

Planetary - JPL 

2. Standard POC System Concept 

As a first step toward maximum standardization, the POCCNET system design 
planned by GSFC is recommended for all Centers. JPL is presently planning a 
similar approach. 

3. Data Base Management Concept 

Anticipated Payload traffic during the early 1980's does not necessitate a 
complex DB management system between Centers; however, a centralized supervisory 
DBM system should be implemented at the earliest opportunity. 

4. Communication and Data Acquisition 

Based on the projected low Phase II Payload traffic and planned bandwidth 
requirements, it is recommended that DOMSATS be implemented when the traffic 
model warrants. 
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TASK e 

• * i * ’ 

SUMAAARY OF ENHANCEMENT. REQUIREMENTS 


• BASELINE NASA PAYLOAD CENTERS 

- GSFC, AUTOMATED EARTH ORBITING PAYLOADS 

- JPL', planetary PAYLOADS 

- JSC, SPACELAB PAYLOADS 

i STANDARD POC SYSTEM CONCEPT 
I DATA BASE SUPERVISORY MANAGEMENT CONCEPT 
e COMMUNICATION AND DATA ACQUISITION 
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TASKf 


DEFINITION OF SYSTEM CONCEPTS 

The objective of Task f is to define feasible, cost effective flight control options 
and develop guidelines for implementation of the options. 

Since this task synthesizes the results of the preceding tasks, the results of this task 
effort in effect reflect the study results. 

The results which will be discussed in detail in the following charts may be summarized 
as fol lows: 

a) Three system concept options were selected and these options have been examined from 
the standpoint of their relation to the system command and control concepts and various 
aspects of their implementation. 

b) The baseline system concept utilizes three payload Control Centers for STS Payloads, 
GSFC for Automated Earth Orbiting Payloads, JPL for Planetary Payloads and JSC for 
Spacelab Payloads. This concept primarily utilizes the existing capabilities of these 
three centers. 

c) The Implementation guidelines include: 

- A four phase approach to the satisfaction of the ultimate requiremnts 

- An evolutionary approach involving a logical sequence of actions, 

- The key decision points are brought to the attention of NASA. 
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TASK f 


OB.JECTIVE: 


SUMMARY OF 
TASK RESULTS: 


DEFINITION OF SYSTEM CONCEPTS 


DEFINE FEASIBLE, COST EFFECTIVE FLIGHT CONTROL OPTIONS AND 
DEVELOP IMPLEMENTATION GUIDELINES 


• THREE SYSTEM CONCEPT OPTIONS EXAMINED 

• BASELINE SYSTEM CONCEPT USES PRIMARILY EXISTING 
CAPABILITIES OF JSC, JPL, AND GSFC 

• IMPLEMENTATION GUIDELINES INCLUDE: 

- 4 PHASE APPROACH TO SATISFACTION OF ULTIMATE 
REQUIREMENTS 

- EVOLUTIONARY APPROACH INVOLVING LOGICAL SEQUENCE 

- KEY DECISION POINTS ARE IDENTIFIED 
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TASKf 


ALTERNATIVES FOR POC LOCATION 

The adjacent chart shows the preliminary listing of POC alternatives for STS Payload 
Control Task b. 

These alternatives were based on the following precepts: 

1. Utilization of an existing single POC for each class of STS payloads; Automated 
Earth Orbiting, Planetary and Spacelab payloads, respectively. 

2. The use of multiple POC's for each ’class of STS payload. 

3. An alternative ,in which each NASA Payload Development Center has its own POC for 
flight control of its payloads. 

This matrix of options was used as a point of departure for the development of system 
concepts in Task f . ’ • • ‘ . 
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TASKf 

SEQUENTIAL FLOW OF SELECTION PROCESS FOR SYSTEM CONCEPTS 

Beginning with the alternatives for POC location on the previous chart, the next step 
is to lay out the individual alternatives by flight type in ai matrix and assign an individual 
alphanumeric designator to. each separate alternative or case. 

I 

Following; thiSj each case is evaluated in a matrix which assesses each applicable system 
element against each selection criteria for each of the flight type categories; A, B and C. 

In the next matrix the scores are summed for each system element under each payload 
class and the .three highest figures of merit for each payload class are entered in the columns 
of the next matnix under Options 1, 2 and 3 in descending order of magnitude. 
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TASK f 

SEQUENTIAL FLOW OF SELECTION PROCESS FOR SYSTEM CONCEPTS 


'ALTERNATIVES 
FOR POC LOCATION 


MATRIX OF POC 
OPTIONS VS FLIGHT TYPES 

















TASKf 


SELECTION CRITERIA FOR SYSTEM CONCEPT OPTIONS 

An initial list of 14 candidate criteria was circulated for coinment by study representa- 
tives of the NASA Centers. Through the coordination cycle, the list was refined and because 
of the problem of overlapping criteria, was reduced to three basic criteria containing a 
total of seven factors as noted on the chart on the facing page. 

These criteria do not apply to all system elements of all cases evaluated; therefore, the 
Task f report contains a matrix of applicability which was used as a guide to the application 
of these criteria in the evaluation process. 

Cost Factors are applicable to either recurring or non-recurring type costs. Due to the 
nature of the system element being evaluated, both recurring and non-recurring costs do not 
apply to the same element simultaneously. 

Operational effectiveness includes a factor entitled "Factors to Enhance Crew Safety." 

It is recognized that crew safety is an STS operator function. However, various system concepts 
for payload support can affect the integrity of the integrated STS/STS Payload Operations Plan and 
thus indirectly affect crew safety. A highly integrated organization for payload operations 
will normally enhance crew safety considerations. 

Responsiveness to users is principally a function of how accessible the system for payload 
operations can be made to the users and the accessibility of engineering support to the real 
time operation of the user's payloads. 
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TASKi 


SELECTION CRITERIA FOR SYSTEM CONCEPT OPTIONS 


•’ COST FACTORS 

NON-RECURRING 

RECURRING 

• OPERATIONAL EFFECTIVENESS 

COMPLEXITY of' INTERFACES 
FACTORS TO ENHANCE CREW SAFETY 
FACILITY LOADING EFFICIENCY 

• RESPONSIVENESS TO USERS 

ACCESSIBILITY OR UTILITY TO USERS 
ACCESSIBILITY TO ENGINEERING SUPPORT 
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TASKf 


DATA IN SUPPORT OF CONCEPT SELECTION 

Concept selection considers the results of the other study tasks. One of the signifi- 
cant inputs to the selection of system concepts is. the analysis, of Task d allocations of 
flight control ground functions. 

The facing chart shows the distribution of allocations for 666 flight control ground 
functions. Selection of flight control ground functions emphasized the integrated flight plan 
so as to include as nearly a complete set of functions requiring the attention of the STS 
Operator as possible. There may be additional functions carried out solely by the Payload 
Control Centers during free flight phases which are not necessarily listed among the functions 
which were allocated. 

Of the functions which were analyzed, approximately 70% require the attention of the STS 
operator in one way or another. This is the primary reason for the recommendation in the 
system command and control concept, for use of an STS Payload Integrated Operations Manager 
to support the payload operational interfaces with the STS Operator. 
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TASKf 


DATA (N SUPPORT OF CONCEPT SELECTION 


SUMMARY OF ALLOCATIONS OF, FLIGHT CONTROL FUNCTIONS 



TOTAL NUMBER OF FUNCTIONS 
WITH POTENTIAL STS INTERFACES 

REPRESENTATIVE FLIGHT TYPES - 

SPECIFIC PAYLOADS/DISCIPLINES 

CATEGORY A - 15 
CATEGORY B - 2 
CATEGORY C - 7 

FLIGHT PHASES CONSIDERED - - 


666 

14 

24 


15 




TASK'f 

DATA IN SUPPORT OF' CONCEPT SELECTION (CONTINUED) 

The next two charts contain a listing of the 14 flight types with 3 additional variations 
on types L, M, and N. .The charts show the duration and number of overlaps encountered each 
year for each flight type. 

Summing the overlaps of all flights in each year provides the basis for the chart- 
which follows, "Analysis of Traffic Model and Flight Overlaps." 
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TASK f 

DATA IN SUPPORT OF CONCEPT SELECTION 

DURATION OF STS PAYLOAD OPERATIONS SHOWING OVERLAPS 


PAYLOAD FLIGHT TYPE AND 
DURATION 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

1991 

A SPACELAB MODULE 

AND PALLET - ATL 
7-30 DAYS 

1 

1 

1 

1 

1 

1 

■ 

11^12 

1 

1 

1 

1 

A SPACELAB MODULE 

AND PALLET - AMPS 
7-30 DAYS 







NO OV 

ERLAP 




' 

C SPACELAB 

PALLET ONLY. SO 
7-30 DAYS 







NOOV 

ERLAP 





C SPACELAB PALLET 

ONLY .. STELLAR 

7-30 DAYS 







NO OV 

ERLAP 





B SPACELAB MODULE 

AND PALLET 
MULTI-DISCIPLINE 
7-30 DAYS 







> 

o 

o 

z 

ERLAP 



(21* 

(2)‘ 









0 SPACELAB, PA'LLET 

ONLY, MULTI DISCIPLINE 
7-30 DAYS 

- 







NOOV 

ERLAP 





J SPACELAB MODULE 

ONLY. DEDICATED 
DISCIPLINE LS 
7-30 DAYS 







NO OV 

ERLAP 





J MULTI-CARGO 

DELIVERY - EXPLORER' 
STP 

2 YEARS 




























ASSUME 6 SHUTTLE FLIGHTS PER YEAR WITH NO OVERLAP, HOWEVER 2 OVERLAPPING PL OPERATIONS DUE TO 
7 FLIGHTS IN 1990 AND 8 FLIGHTS IN 1991 
















TASK f 

DATA IN SUPPORT OF CONCEPT SELECTION (CONTINUED) 


(Continued from previous page) 
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, TASK f 

DATA IN SUPPORT OF CONCEPT SELECTION (CONTINUED) 

DURATION OF STS operations showing’ OVERLAPS (CONTIIMUEDI 


PAYLOAD FLIGHT TYPE AND DURATION 

1980 

1931 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

1991 

i 

L lUS PLANETARY 

, mariner 

7 YEARS 

1 


!■■■■ 




!BB 





1 


1 


— 

— 






N TUG PLANETARY, 

PIONEER 
5 YEARS 

1 


1 




1 

— 


1 

■ 

— 


IHBJSS 



— 

■I 



K'M lUS'rUG 

MULTI SATELLITI , . 

COMSAT, DISASTER WARNING 

1 


1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

F LEO DELIVERY AND 

RETRIEVAL. LSI 
3 YEARS 

1 


1 



— 


— 


=== 


1 

1 MULTI-CARGO, 

LEO. DELIVERY, 
BESS,SEOPS 

6 MOS/7 DAYS 

1 


1 

1 

1 

1 

1 

1 

1 





G LEO REVISI WITHOUT 

EVA, EOS 
2-7 DAYS 

1 


1 

1 

■ 



1 

1 

1 




H LEO PlVISIT WITH 

EVA, LST 
2-7 DAYS 

1 

1 


Nt 

OVER 

LAP 







L/N 1 US/TUG 

SINGLE SATELLITE, 

2-5 YEARS 

1 

1 

. 

(NOTC 

1 

ONTR( 

NO OV 
DLLED 

ERLAF 
BY NA 

SA FAC 

(LITY) 





M TUG DEDICATED 

RETRIEVAL 
3 DAYS 

1 

1 

1 




1 

1 

1 
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TASK f 

DATA IN SUPPORT OF CONCEPT SELECTION (CONTINUED) 

The two graphic plots on the f acting page show the number of STS payload flights per 
year taken from the study traffic model and the number, of payload reference flight types 
which overlap in duration (shown in the shaded area). 

It can be seen that the major load imposed on the payload support capabilities by the 
overlap of long duration flights lags the build-up of launches by approximately 2 years. 
The number of long duration flights by complex payloads which occur simultaneously is as 
important an indication of the workload placed on payload supporting resources as the 
frequency of launches. 
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TASK f 

DATA IN SUPPORT OF CONCEPT SELECTION 
ANALYSIS OF TRAFFIC MODEL AND FLIGHT OVERLAPS 
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TASKf 


SYSTEA/l CONCEPT OPTIONS SELECTED 

This' chart shows the system concept options finally selected as a basis for further 
evaluation of STS payload support requirements. 

Option 1 (baseline system) utilizes the extant capabilities of GSFC, OPL and JSC for 
control of the three classes of payloads historically supported by those centers. NASA/ ARC 
is shown as the POC for Pioneer spacecraft since it currently provides a remote control center 
with established interfaces with the JPL SFOF and the DSN. 

In Option 2 concept the support of Automated Earth Orbiter Payloads has been extended 
to include JSC and the operational loads imposed by an increase in spacelab flights is 
supported by GSFC. 

Option 3 considers a philosophy in which all Payload POCC's would be standard and any 
POCC could support any payload with quick turn-a-round times for reconfiguration. In this 
concept a portable combined DOMSAT Terminal/POCC would support operations from other NASA 
development Centers or remote users as an extension of an existing POC. 
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• fASKf ; 

SYSTEAA CONCEPT OPTIONS. SELECTED 


OPTIONS 



, 1 . 

2 

3 

AUTOMATED EARTH 
ORBITING PAYLOADS 

GSFC . 

GSFC/JSC 

GSFC 

. ■ . JPL 
JSC 

i - 

PLANETARY PAYLOADS 

JPL - ARC, . 

JPL - ARC 

SPACELAB PAYLOADS 

JSC 

JSC/GSFC 

'■ V ... 

■k 


*STANDARD POCC's SUPPORT ANY TYPE PAYLOAD WITH PORTABLE 
DOMSAT TERMS/ POCC's FOR USE AT OTHER CENTERS. 
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TASKf 


CONFIGURATION OF SYSTEM ELEMENTS - CONCEPT NO. l' 

The configuration in this concept includes the' three CenteVs for prime control of the 
three payload classes and the remote POCC for Pioneer at ARC. All POC's are tied into the 
launch and landing sites, the MCC-H, and the data acquisition facilities via the NASCOM net.* 
The DOD Satellite Test Center can communicate with NASA POC's and the MCC-H for handover 
operations when necessary. 

Each of the POC's in the baseline system include functional capabilities, as follows:. 

1. Ground Communications 

2. Tracking data analysis and orbit determination 

3. ' Information processing 

4. Payload science and engineering analysis 

5. A data base- system 

6. One or more POCC's. 
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. TASKf 

CONFIGURATION OF SYSTEM ELEMENTS -.CONCEPf NO.' 1 

































TASK f 


CONFIGURATION OF SYSTEM ELEMENTS - CONCEPT NO. 2 

This configuration shows the dual purpose configurations for GSFC and JSC as they expand 
their capabilities to support both Automated Earth Orbiting and Space! ab Payloads. 

In this configuration a payload coordinator for each class of payload has been added to 
coordinate all payloads of a given class between centers and provide the interface for his 
class of payloads with the MCC-H. 

Planetary Payload orbit determination is shown as a separate function at JPL. 
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TASK f 

CONFIGURATION OF SYSTEM ELEMENTS, CONCEPT NO. 2 



SYSTEM 

NOCC 


P.L. ENR 
ANALYSIS 


P.L. SCI 
ANALYSIS 


GSFC - POC 
AUTOMATED 
EARTH ORBITING 
PAYLOADS 


AUTO E.O. 
POCCs 




STS PAYLOADS 
INTEGRATED 
OPERATIONS 
MANAGER 


EARTH ORBITING 

DAVLOAO 

COORDINATOR 


SPACE LAB 

PAYLOAD 

COORDINATOR 


LAUNCH AIID LAMDIilG OPERATIONS 


AUTO E.O. 
POCCs 


P.L. ENG 
ANALYSIS 




OSC - POC 
SPACELAB 
PAYLOADS 


P.L. SCI 
ANALYSIS 


PLANETARY 

PAYLOAD 

COORDINATOR 


PLANETARY 
ORBIT DET 


P.L. 

SCI A ENG 
ANALYSIS 


JPL POC - PLANETARY PAYLOADS 
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:-;rJASKf ■ 

. * i “■ ' 

CONFIGURATION OF SYSTEM ELEMENTS - CONCEPT NO. 3 • 

■V 

This configuration depicts the arrangement of system elements for the concept involving 
a NASA-wide integrated system of standard POCC's. Each POC works through a payload coordinator 
for a given class of payloads in interfacing with either the MCC-H or portable remote DOMSAT 
TERMINAL/POCC’s. 

This concept will be explained in further detail later under the command and control 
concept discussion. 


f-23 




f-24 















TASKf 


COMMAND AND CONTROL CONCEPT NO. 1 

1 

t * 

This chart shows the command and control concept recommended for the baseline system 
concept. The solid lines on the chart indicate command and control channels. The dashed 
lines are information channels used during launch and landing operations. 

An Integrated Operations Manager (lOM) provides a standard interface between the MCC-H 
and Payload Coordinators for the three classes of payloads. NASA Headquarters obtains 
payload operational status from and passes policy information through the Integrated Opera- 
tions Manager on all matters requiring attention at that level. 

The Payload Coordinator (PC) for each class of payloads coordinates matters between all 
POCC's supporting a given class of payloads and presents a standard interface between the- POCC 
and the lOM. 

POCC's act as agents for both the user and the NASA Development Centers for real time 
operational matters. 

Users may work closely with POCC's through the use of host facilities to interface with, 
the operational environment. 
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TASK f 


COMMAND AND CONTROL CONCEPT NO., I . 
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TASKf 


COMIVIAND AND.CONTROL CONCEPT NO. 2 ' 

This concept for'command and control applies to either system Configuration' 

No. 2 or 3. . • 

The function of the’ Integrated Operations Manager (lOM) is the same as for Concept 
No. 1. The Payload Coordinators (PC) functions are expanded in this command and control 
concept. to include not only the coordination of POCC's within a NASA Center but to include 
all Centers and all remote portable DOMSAT TERM/POCC's utilized to support a class of 
payloads. 

This concept functions in an' environment where all POCC's are standard and can support 
any class of payload. This places an increased burden on the PC to be responsible for all 
unique aspects of ah operation for a particular class of payloads. 

The portable remote DOMSAT TERM/POCC will have the capability to function as a standard 
POCC drawing additional support from the lead NASA POC for the appropriate class of payloads 
Although Payload Commands may be generated at the portable POCC, they must be checked and 
enabled by the parent POC and/or the MCC prior to being transmitted to a payload. 
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TASK f 

COMMAND AND CONTROL CONCEPT NO. 2 



LEGEND: SOLID LINES « PRIME COMMAND AND CONTROL CHANNELS 
DASHED LINES » LAUNCH AND LANDING INFORMATION NET 
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TASK.f 


- STS PAYLOAD OPERATIONAL INTERFACES • ’ 

,W ITH THE STS 0 PERATOR AT THE IVICC-H 

The facing block diagram shows the organization' of the STS Operator team in the 
Mission Operations Planning Room (MOPR). 

The dotted lines show the interfaces between the STS Payload Integrated' Operations 
Manager (lOM) and the Payload Integrator for MOPR and between the Spacelab Payload 
Coordinator and the Flight Control Rooms at MCC-H. Another alternative would be for the 
lOM and the Payload Integrator to merge their functions into a single function. 
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TASK f 


STS PAYLOAD OPERATIONAL INTERFACES 
WITH STS . OPERATOR AT THE MCC-H • • 



INTER-ORGANIZATIONAL LINES 


REAL-TIME OPERATIONS INTERFACES 

PAYLOAD OPERATOR/STS OPERATOR 

OPERATIONS COORDINATION 
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TASKf 


LOGICAL COMBINATIONS OF PAYLOAD SUPPORT FUNCTIONS 

Once a three level hierarchy is considered for payload command and control, various 
functions may be performed optionally at one or more of the levels. 

For example, the command and control concept involves a flight director within a POCC, 
a Payload Coordinator for all payloads of a single class at the POC and an Integrated Opera- 
tions Manager for coordination of payload operations of all classes. This organization 
provides fertile ground for a number of trade-offs relative to what functions should be optimally 
combined at the various levels for the most cost-effective operation. The next two charts 
provide a list of some of the functions and some tentative recommendations. This subject 
should be studied in more detail than was possible during this study. 
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■ TASKf 

LOGICAL COMBINATIONS OF PAYLOAD SUPPORT FUNCTIONS 




FUNCTIONS WHICH 
CAN BE COMBINED 
FOR ALL CLASSES 
OF PAYLOADS 

FUNCTIONS WHICH 
CAN BE COMBINED 
FOR ALL PAYLOADS 
OF A CLASS 

FUNCTIONS WHICH 
MUST RESIDE AT 
EACH POC 

1. 

PAYLOAD COMMAND ACTIVITIES 



X 

2. 

TRACKING DATA ANALYSIS AND 
ORBIT DETERMINATION 


X 


3. 

PREPROCESSING OF TELEMETRY 
DATA AT ACQUISITION SITE 

X 

X 


4. 

PREPARATION OF USER DATA TAPES 



X 

5. 

PROCESSING AND DISPLAY OF REAL 
TIME TELEMETRY 



X 

6. 

REAL TIME SIMULATIONS 

' 


X 

7. 

ATTITUDE DETERMINATION AND 
POINTING 

' 


X 

8. 

PROCESSING OF WIDE BAND DATA 
AND VIDEO ENHANCEMENT 

X 

X 


9. 

SCIENCE PAYLOAD SUPPORT OF 
REAL TIME OPERATION 



X 

10. 

ENGINEERING PAYLOAD SUPPORT 
AND CONTINGENCY ANALYSIS 



X 

n. 

CONSUMABLES MONITORING 



X 
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TASKf 


LOGICAL COMBINATIONS OF PAYLOAD SUPPORT FUNCTIONS (CONTINUED) 


(Continued from previous page) 
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LOGICAL COMBINATIONS OF PAYLOAD SUPPORT FUNCtioNS (CONTINUEB) " 




FUNCTIONS ’WHICH 
CAN BE COMBINED 
FOR ALL CLASSES 
OF PAYLOADS 

•FUNCTIONS WHICH 
CAN BE COMBINED. 
FOR ALL PAYLOADS 
OF A CLASS 

FUNCTIONS- WHICH 
MUST RESIDE AT 
EACH POC 

12. 

MAINTEMANCE OF OPERATIONAL 
INTERFACES WITH LAUNCH FACILITY 

. ■ 

■ X ■ 

.• ■ X- 

13. 

OPERATIONS SCHEDULING AND REAL 
TIME REPLANNING 

. , . 

• . X 

■'•'X 

14. 

DATA BASE -MANAGEMENT, STORAGE - 
AND RETRIEVAL 


. , X 

/ -X- 

15. 

GROUND COMMUNICATIONS, SWITCHING, 
ROUTING, DATA LOGGING, ERROR 
CORRECTION, ETC. 

X 



16. 

NETWORK CONTROL, AND SCHEDULING 

X 



17. 

OPERATIONAL USER LIAISON 



X 

18. 

OPERATIONAL INTERFACE BETWEEN 
PAYLOAD OPERATOR AND STS 
OPERATOR 

X 

X 


19. 

COMPUTER PROGRAMMING SUPPORT 
AND MAINTENANCE 


X 

X 

20. 

ADMINISTRATIVE SUPPORT 

X 

X 

X 

21. 

FACILITY AND EQUIPMENT 
MAINTENANCE 

X 

X 

X 
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TASKf 


COMMUNICATIONS ELEMENT 


One of the five elements used to define a system concept for STS Payload Operations 
is the; communications element. 

The diagram on the facing page contains in the solid lines the basic communications 
resources required for the baseline system. 

The dashed lines show the additional POC's that might be utilized in the control of 
STS payloads through the use of standard portable POCC's working through DOMSAT terminals 
at each of the three baseline POC's. 
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TASKf 


COMMUN ICATI ONS ELEMENTS' OF SYSTEM CONCEPTS 



OOMSAT if 
TERM. ^ SO MB/S 



LINES AVAILABLE FROM AT & T. 
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TASKf ■ 


QPERATIONALTEAM STRUCTURES FOR REALTIME 

The command and control concepts for STS payloads require the operational team structures 
for the real time operation that are shown on the facing page. 

I 

The Launch support team consists primarily of personnel from the payload contractor's 
integration and test crew. This team has an operational interface with the POCC during the 
prelaunch and launch activities at KSC or VAFB. 

The Payload Class Coordinator is resident at each of the lead centers for a class of 
payloads. His team is responsible for coordinating the operation of all POCC's in support 
of his assigned payload class. 

The Integrated Operations Manager coordinates the overall STS payload operational activities ■ 
with the STS Operator. In addition, he maintains the interface with NASA Headquarters for 
real time payload operational matters. 

The functions of the POCC teams are similar to existing organizations for payload opera- 
tions except that network liaison may be a more appropriate function of the Payload Class 
Coordinator. 
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TASKf 

OPERATIONAL TEAM STRUCTURES FOR REAL TIME OPERATIONS 


• PAYLOAD LAUNCH SUPPORT TEAM 
o PAYLOAD CLASS COORDINATOR 

• INTEGRATED OPERATIONS MANAGER 

• POCC TEAMS 

- OPERATIONS DIRECTOR 

- COMMUNICATIONS AND' DATA 

- NETWORK LIAISON* 

‘ - ORBIT DETERMINATION 

- ■ DATA BASE' MANAGEMENT 

- SPACE SCIENCE SUPPORT TEAM 

- PAYLOAD ENGINEERING SUPPORT TEAM 

- DATA PROCESSING SUPPORT TEAM . 

- TRAINING, AND SIMULATION 


*THIS FUNCTION MAY BE PERFORMED BY PAYLOAD CLASS COORDINATOR 
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TASKf 

DRIVERS FOR SYSTEM IMPLEMENTATION. 

The five major drivers, for system implementation as .listed on the facing pages are: 

1. Cost Minimum cost dictates the use of existing' facilities for as long as 

possible. Cost will also be minimized by standardization and as new 
systems are phased in, standardization can be achieved. 

2. Flight Rate As the traffic model builds toward peak levels the system capabilities 

Build-Up should expand to accommodate the load. Based on the traffic model, 

the logical time phased support capability would seem to be 1980 for 
the initial capability, 1983 for an incremental enhancement and 1986 
for the final system capability. 

3. Increasing Numbers Most flight overlaps occur with Planetary and Large complex free flyer 

of Flight Overlaps payloads. As overlaps build up the, requirements on data handling 

capacity^ computation capacity and team structures will increase. Data 
compression or filtering at the source should be considered as a means 
of constraining the ultimate system capacities. 

4. Common Payload The focal point during certain flight phases for an increasing number of 

Interfaces With operational functions will be the interface with MCC-H. Simplification 
MCC-H and standardization of interfaces and operating procedures will minimize 

this impact. 

5. Accommodation of Spacelab payloads will be the largest single class of payloads to be 

Spacelab Payloads accommodated. Since these payloads are all short duration (7-30 days), 

the POCC systems at the various centers should be capable of spacelab 
payload support with quick turn-a-round times. Standard POCC's would 
facilitate this concept. 
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TASK f 


DRIVERS FOR SYSTEM IMPLEMENTATION 


•' COST 


• FLIGHT RATE 
BUILD-UP 


• INCREASING NUMBERS 
OF FLIGHT OVERLAPS 

• COMMON PAYLOAD 
INTERFACES WITH MCC-H 

• ACCOMMODATION OF 
SPACELA8 PAYLOADS 


DRIVES TOWARD USE. OF EXISTING CAPABILITIES, 
STANDARDIZATION OF SYSTEMS AND PROCEDURES; 

SYSTEM VERSATILITY. 

SUGGESTS TIME PHASED IMPLEMENTATION; IMPROVED 
SYSTEM TURN-A-ROUND TIMES; ENHANCED DATA HANDLING 
CAPABILITIES. 

CONSIDERATION FOR MULTIPLE RESOURCES FOR DATA 
HANDLING, COMPUTATION, TEAM STRUCTURES; ULTIMATELY 
FOR DATA COMPRESSION/FILTERING AT SOURCES. 

DRIVES TOWARD STANDARD OPERATING INTERFACES AND 
PROCEDURES. 

SPACELAB PAYLOADS TO BE LARGEST SINGLE CLASS, ALL 
SHORT DURATION. ALL POCC'S SHOULD BE STANDARD 
AND CAPABLE OF SPACELAB PAYLOAD SUPPORT. 
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I M PLEAAENT AT 1 ON R ECOiyiMEN D AT 1 0 N S ' 


Based on the implementation drivers previously listed, a four phased approach is recommended. 
The ultimate system for STS payload support is a fully integrated, standardized, multi-center 
NASA-wide system. Cost is the major driver for such a system. With a relatively constant NASA 
budget and with steadily increasing requirements coupled with continued inflation, improved effi- 
ciency is the only solution. 

TRW recommends that the following areas be explored as potential ways to improve efficiency 
and reduce costs. 

a. Standardized payload data and command formats and multiplexing schemes, standard 
operational procedures and system interfaces. 

b. Integration of NASA payload support resources into an overall NASA-wide system. 

c. An evolutionary, time phased building block approach to phase in new capabilities just 
ahead of the requirements stemming from increased loads on the system. 

d. The GSFC POCCNET concept should be invest! gated. for applicability to all payload centers 
and the feasibility of extending the- concept to include a capability for netting the 
resources of the various centers together in a common network should be explored. 

e. Improving POCC utilization through standardization and rapid reconfiguration capability. 
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1 AA PLEMENTAT lbN RECOMMEND At 10 N S 


. » A FOUR PHASED EVOLUTIONARY APPROACH IS RECOMMENDED FOR AN 'INTEGRATED., MULTI-CENTER 
NASA-WIDE SYSTEM FOR STS PAYLOAD SUPPORT. ’ . . ' ... 

- - COST- IS MAJOR DRIVER. WITH CONSTANT NASA BUDGET COUPLED WITH INCREASING REQUIREMENTS 

AND CONTINUED INFLATION, IMPROVED SYSTEM EFFICIENCY IS ONLY SOLUTION. 

• RECOMMENDED AREAS FOR EXPLORATION LEADING TO IMPROVED SYSTEM EFFICIENCY ARE: 

- STANDARDIZATION OF PAYLOAD DATA FORMATS, SYSTEM INTERFACES AND OPERATING PROCEDURES. 

- INTEGRATION OF NASA PAYLOAD SUPPORT RESOURCES INTO NASA-WIDE SYSTEM. 

■ - A TIME PHASED BUILDING BLOCK APPROACH WHICH BUILDS CAPABILITIES JUST AHEAD OF 

REQUIREMENTS, BASED ON EXISTING CAPABILITIES OF CENTERS FOR INITIAL FLIGHT PHASE. 

- EXTEND THE .GSFC POCCNET CONCEPT TO ALL CENTERS WITH PAYLOAD CAPABILITY AND EXTRAPOLATE 
INTO .A NASA -WIDE INTEGRATED SYSTEM. - 

- IMPROVE POCC UTILIZATION' FACTOR. STANDARD POCC'S WOULD SUPPORT ANY PAYLOAD ON SHORT 
TURN -A- ROUND BASIS. 
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TASKf 


PHASED IMPLEMENTATION APPROACH 


Phase I extends from 1976 to 1980. During this period the requirements should be defined for 
the ultimate system for STS payload support and implementation planning should be completed along 
with the scheduling of enhancements required to evolve from the baseline system to the ultimate 
system in a logical building block approach. The studies identified on the opposite page should 
be completed in order to confirm the feasibility of a fully integrated NASA-wide approach to STS 
payload support and to provide a basis for implementing the various system enhancements. 

A major effort to be completed during Phase I is the design and implementation of a POCC 
system to support Spacelab payloads. 

In order to insure the capability to support initial phase II STS payloads of the Planetary 
and Automated Earth Orbiting types, the existing plans for enhancement of the GSFC and JPL POCC 
capabilities and communications systems to support TDRSS should be completed. 

The lead times for introducing design standards into payloads are necessarily long. There- 
fore, the definition' of standards should begin early and they should be introduced at the earliest 
practical time in order to be effective during phase III and. IV. 
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PHASED IMPLEMENTATION APPROACH 


PHASE I - 1976 TO 1980 - REQUIREMENTS DEFINITION - .IMPLEMENTATION OF BASELINE SYSTEM 

• COMPLETE STUDIES- TO DEFINE NASA-WIDE STS PAYLOAD SYSTEM INTEGRATION AND IMPLEMENTATION 
APPROACH. 

- REFINE PAYLOAD REQUIREMENTS FOR LONG RANGE SUPPORT 

- DEFINE PAYLOAD STANDARDS FOR COMMUNICATIONS, DATA FORMATS, COMMAND SYSTEMS, POCC'S- 

- TECHNOLOGY ASSESSMENT STUDIES - STANDARD FIRMWARE TO REPLACE SOFTWARE. 

- DEFINE HOST FACILITIES TO PROVIDE STANDARD USER SUPPORT FUNCTIONS AND INTERFACES. 

- INVESTIGATE IMPLEMENTATION OF PORTABLE REMOTE POCC OR DATA MONITORING FACILITY WITH 
DOMSAT TERMINAL. 

• - MAKE TRADE-OFFS FOR EXPANSION OF THREE CENTER BASELINE SYSTEM CAPABILITIES VS 
ADDITIONAL CENTERS AS PAYLOAD OPERATIONS CENTERS. 

- DETERMINE IMPLEMENTATION APPROACH FOR STANDARD DATA TRANSFER CAPABILITY BETWEEN CENTERS. 

- DEFINE A SUPERVISORY CENTER WIDE DATA BASE MANAGEMENT SYSTEM FOR PAYLOAD OPERATIONS, 

- DEFINE A STANDARD POCC WITH QUICK TURN-A-ROUND CAPABILITY. 

- ESTABLISH STANDARDS AND REQUIREMENTS FOR DATA COMPRESSION FOR LONG TERM HIGH DATA RATE 
PAYLOADS. 

t DESIGN AND IMPLEMENT SPACELAB POCC CAPABILITIES. 

• AUGMENT BASELINE CENTERS FOR PAYLOAD SUPPORT- IN ACCORDANCE WITH. EXISTING PLANS FOR SUPPORT 
OF PHASE II PAYLOADS. THIS INCLUDES TDRSS GROUND COMMUNICATION SUPPORT CAPABILITY. 

• BEGIN INTRODUCING STS PAYLOAD STANDARDS TO BE EFFECTIVE IN PHASE III AND IV. 



. TASKf 


PHASED IMPLEMENTATION APPROACH' 

^ ' ' ' 


Phase II extends from 1980 to 1983., During 1983 the flight traffic model for STS payload 
launches increases from 44 to 77 percent of the total peak traffic. In addition, flight overlaps 
more than double with an increase from 8 to 19 during 1983. This buildup in launches and flight 
overlaps during 1983 indicates a significant increase in ground support activity levels. and thus 
appears to be the logical break point for phasing in additional enhancements for use during 
phase III. Enhancements recommended for phase II in support of phase III should be fully opera- 
tional no later than mid 1983. The additions recommended for implementation during phase II include 
the items on the adjacent page. 

The STS payloads launched prior to 1983 should be adequately supported by an augmented existing 
capability with the addition of a POCC system for Spacelab payloads. The timing for installation of 
a DOMSAT terminal at the Payload Control Centers will depend upon the communications traffic analysis 
for the various system nodes. Some centers may require DOMSAT communications or other wideband 
ground link enhancements to be operational during phase II. 
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^ task f 

PHASED IMPLE/VIENTATION: APPROACH 

PHASE II - 1980 TO 1983 - BASELINE SYSTEM - AUGMENTED EXISTING CAPABILITY; IMPLEMENTATION 
FOR PHASE III. 

§ 'INTRODUCE DOMSAT TERMINALS AT POCS.’ 

9 INTEGRATE CONTROL AND SCHEDULING OF ALL PAYLOAD TRACKING AND DATA ACQUISITION FACILITIES 
UNDER A SYSTEM NOCC. . . 

e INTRODUCE FULLY COMPATIBLE SYSTEM FOR INTERCENTER DATA TRANSMISSION. 

I ESTABLISH SUPERVISORY DATA BASE MANAGEMENT SYSTEM UNDER .CENTRAL AUTHORITY.. - . 

$ IMPOSE STANDARDS FOR DATA FORMATS, COMMAND SYSTEMS AND STRIPPING/PROCESSING DATA FOR STS 
PAYLOADS. - . ■ . 

'• INTRODUCE STANDARD OPERATING PROCEDURES FOR 

- REAL TIME MODIFICATION OF FLIGHT' PLANS 

- PRIORITY SCHEMES FOR RESOLVING CONFLICTS IN RESOURCES REQUIREMENTS 

- AUTOMATED SCHEDULING SYSTEMS 

- COMPUTERIZED DOCUMENTATION GENERATION AND UPDATE 

- HIGH SPEED, HIGH RESOLUTION FACSIMILE FOR TRANSFER OF HARD COPY BETWEEN REMOTE OPERATORS. 
9 ESTABLISH OPERATIONAL INTERFACES WITH VAFB. 


f-46 



TASK f 


■ PHASED IMPLEMENTATION APPROACH 


Phase III extends from mid 1983 through mid 1986. This is termed the transition phase since 
it is during this phase that TRW recommends completing transition from a system of unique support 
facilities for various payload classes to a totally integrated, standardized system where any POCC 
can support any payload. 

Since phase IV requires a full capability to support the maximum number of launches and flight 
overlaps, implementation of the full systems capability should be completed during phase III to be 
operational at the start of phase IV. 

The facing page lists the system features recommended for implementation during phase III. The 
major thrust of the activity recommended for this phase is to finalize a standard operational inter- 
face with the TUG, phase in the changes necessary to make all POCCs standard and provide a system of 
portable POCC/DOMSAT Terminals to interface remote users and/or additional centers with the standard 
'NASA-wide network for Payload control. 
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task f 

'PHASED IMf’LEMENTATiO.N APPROACH. . . 

PHASE III - 1983 TO 1986 - TRANSITION PHASE - IMPLEMENTATION FOR PHASE IV 

• STANDARDIZE OPERATIONAL INTERFACES WITH TUG 

• PHASE IN STANDARD OPERATING CONSOLE MODULES AT ALL POCC'S. 
e INTRODUCE STANDARD DISPLAY SYSTEMS FOR ALL POCC'S. 

« IMPLEMENT STANDARD POCC DESIGNS NECESSARY FOR ANY POCC TO SUPPORT ANY- PAYLOAD AND TO 
PERMIT RECONFIGURATION WITHIN 10 TO 15 DAYS. 

0 IMPLEMENT STANDARD USER INTERFACES WITHIN HOST FACILITIES FOR USERS TO ACCESS THE 
INTEGRATED SYSTEM. 

• PROVIDE A SYSTEM OF PORTABLE POCC/DOMSAT TERMINALS TO INTERFACE REMOTE CENTERS OR 
USER FACILITIES WITH HIGH DATA RATE REQUIREMENTS INTO THE NASA SYSTEM. OPERATION 
OF SUCH A FACILITY WOULD BE UNDER THE DIRECTION OF AN ESTABLISHED POC. 



. TASK f 

PHASEDJIVlPLEiVlENTATipN. APPROACH 


Phase IV extends from mid 1986 through 1991. The fully integrated NASA-wide STS Payload Support 
System should be completed by 1986 in order to accommodate the full traffic model for- payload 
launches. 

The recommended system will have the advantage of maximum flexibility to respond to changes 
in payload support requirements during the remainder of the STS operational era. By netting together 
the NASA resources for computer support, having wide band real time capability for data transfer 
and capability for quick reconfiguration of POCCs, the system will maximize responsiveness to new 
or changing requirements. 
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TASKf 


PHASE, D IMPLEMENTATION APPROACH 


PHASE IV ~ MID 1986 THROUGH 1991 -FULLY INTEGRATED NASA-WIDE STS PAYLOAD 
SUPPORT SYSTEM. 

. f SYSTEM SUPPORTS FULL TRAFFIC MODEL. 

• ALL SYSTEM ENHANCEMENTS COMPLETE AT BEGINNING OF PHASE IV. 

• THE RECOMMENDED INTEGRATED NETWORK OF 'NASA PAYLOAD CENTERS WILL PROVIDE 
MAXIMUM FLEXIBILITY FOR RESPONSE TO CHANGES DURING REMAINDER OF STS 
OPERATIONAL ERA. 
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■ TASK f 

- - IMPLEMENTATION MILESTONE SCHbULE 

This schedule covers the recommended schedule of implementation activities and program 
phases, beginning in 1976 and extending through the 1991 time frame. All implementation 
activities are completed by 1986 .which is the beginning' of Phase IV. At this time the NASA- 
wide STS payload support system will begin to experience peak traffic loads resulting from 
a fully mature Space Transportation System. 

The scheduling of system enhancements is designed to produce an evolutionary approach 
to meeting the increasing requirements, of the STS payloads at key points while the requirements 
build toward the peak load. In addition, the phasing of enhancements provide an evolutionary 
building block approach which minimizes the impact on the existing system at any point in time. 
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TAS;1< f 

i 

IMPLEMENTATION MILESTONE SCHEDULE 



1983 1984 toss 


III -TRyWSITIW 

• MILO TOWARD FULL CAPABILITY 

• IKPLEHENTATION FOR PHASE IV 


1 STS PAYLOADS aEoymewENTS 


DEFINITION ReFINEMENTSTUOieS 


2 TECHNOLOGY ASSESSMENT STUDIES 


3 SYSTEM TRAPS STUOY-EXPAND 






4 DEVELOP STANDARDS FOR PAYLOAD 


OPERATIONS ANOQATA SYSTEMS 


6 DESIGN PHASE I SPACELA3 POC 


6 IMPLEMENT PHASE II SPACELAB POC 


7 tWPLEMENTPR 


AUGMENTATION OF GSFC. JPL POCs 


8 AUGMENT NASCOM CAPABILITY FOftTORSS 


9 OBTAIN DOMSAT COMMITTMENT FROM 


CARRIERS FOR 1983 AND FORWARD 


10 ESTABLISH STANDARDS AND RFQIJI REMSNTS 


BiggiingHgiii^ 
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FOR DATA COMPRESSION FOR NEW PAYLOADS 


11 MAKEDgClSlONSONESTAaLISHMgNTOF 


ADDITIONAL POCs -MSFC. ARC, LoRC 
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16 ESTABLISH OPERATIONAL INTERFACES 


WITH VAFB 




18 STANDARDIZE OPERATIONAL INTERFACES 


19 implement STANDARD DATA HANDLING AND 




20 INTRODUCE HOST FACILITIES WITH STD 


INTE RFACES INTO NASA SYSTEMS 


21 STANOAnOlZEALLPOCtATALLNASA 


CENTERS 


22 INTEGRATE ON-LINE ENG, 'SCI ANALYSIS 


AND SIM FROM DEV CENTERS INTORT OPS 


23 IMPLEMENT STANDARD OPERATIONAL INTER- 


FACES WITH SMCC FOR ALL P.LJ 
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TASKq 

RESOURCES MODEL AND ESTIMATING 

The objective of this task is to establish a resources estimating methodology and to apply 
it to estimating non-recurring and recurring resources requirements for the concept chosen in 
Task f by NASA for STS payloads flight control. 

The methodology developed uses standard resources elements and estimating relationships. 
Types of models that have been evaluated include the "Initial Cost" model, "Life Cycle" model 
and the "Present Value" model ("Discounted Life Cycle"). 

Data to be used in Resources estimating for the chosen system concept have been collected 
throughout the study, principally in Task c. 

The resources estimating methodology, model and results for the selected concept will be 
documented and delivered as Volume II-G of the Final Report. 



OBJECTIVE: 


SIJMf4ARY 
OF TASK 
RESULTS: 


•' TASK g 

RESOURCES lyiODEL AND ESTIMATING 

DEVELOP/ESTABLISH RESOURCES ESTItlATIflG METHODOLOGY AIID MODEL, 

AND APPLY TO ESTIMATE RESOURCES FOR NASA-SELECTED CONCEPT. 

• ESTABLISHED RESOURCES ESTIMATING METHODOLOGY 

• IDENTIFIED APPLICABLE MODELS 

• DEVELOPED/IDENTIFIED ELEMEilTS FOR USE IN RESOURCES ESTIMATING 
c ACTUAL ESTIMATING REMAINS TO BE DOME. 

® NON-RECURRING AND RECURRING RESOURCES REPLACEMENT CONSIDERED. 



STS PAYLOADS MISSION CONTROL STUDY 
SUMMARY OF CONCLUSIONS AnU RECOMMENDATIONS 

The introductipvi of a common interface with the STS Operator for all STS payloads establishes 
the need for an integrated approach to STS payload operations. 

A system involving standard POCC's with the capabil-ity to support any payload on a quick 
turn-around basis will provide a higher utilization factor for POCC's and reduce the total number 
of POCC's required for STS payload support. 

If the concept of standard-POCC's is adopted it will be necessary to establish early require- 
ments for payload operational standards. This requirement should be phased in gradually over a 
considerable period of time so as not to impact payload designs .presently under way. At the same 
time, standards should be defined early so as to permit NASA to negotiate them into new payload 
designs during the formulative stages of the various programs. . , 

A key decision to be made as early as possible is whether to expand the capabilities of the 
three baseline centers to support all payloads or augment the capability of additional centers to 
support the increasing load during later phases of the STS payload era. 

A major stride in system enhancement for the users will be the introduction of portable POCC/ 
DOMSAT Terminals to provide wideband communications and control capability for remote users or addi- 
tional centers as an extension of the POCC at one of the baseline centers. 
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STS PAYLOADS. /VliSSION CONTROL STUDY 
SUMMARY OF CONCLUSIONS AND RECOMMENDATIONS 

• AN INTEGRATED, STANDARDIZED, MULTI -CENTER SYSTEM FOR ALL STS PAYLOADS APPEARS TO OFFER THE 
MOST COST EFFECTIVE APPROACH TO STS PAYLOAD COMMAND AND CONTROL. EXTENSION OF GSFC POCCNET 
CONCEPT TO ALL CENTERS SHOULD BE INVESTIGATED AS A POTENTIAL APPROACH. 

• THE -ULTIMATE SYSTEM IS ONE IN WHICH ALL POCC’S ARE STANDARD AND EACH POCC CAN HANDLE ANY 
PAYLOAD ON A QUICK TURN-A-ROUND BASIS. 

0 EARLY ESTABLISHMENT OF NASA-WIDE POLICY ON OPERATIONAL AND DESIGN STANDARDS FOR PAYLOADS 
IS A NECESSARY PREREQUISITE TO ACHIEVING STANDARD GROUND SUPPORT SYSTEMS FOR PAYLOAD FLIGHT 
OPERATIONS. STANDARDS SHOULD BE IMPOSED ON: 

- COMMUNICATIONS AND DATA FORmTS 

- COMMAND SYSTEMS 

- DISPLAY FORMATS 

- DISTRIBUTED DATA BASES 

- OPERATIONAL PROCEDURES AND INTERFACES 

- REQUIREMENTS FOR DATA COMPRESSION AT THE SOURCE 

0 A KEY DECISION, NECESSARY EARLY IN THE IMPLEMENTATION CYCLE IS: 

a) SHOULD THE THREE BASELINE POC'S BE EXPANDED TO ACCOMMODATE FULL TRAFFIC MODEL 
REQUIREMENTS? OR 

b) SHOULD ADDITIONAL CENTERS BE AUGMENTED TO SUPPORT THE INCREASING OPERATIONAL LOAD? 

0 PROVIDE A STANDARD INTERACTIVE SYSTEM TO IMPLEMENT THE VARIOUS USER INTERFACES WITH 
PORTABLE DOMSAT TERMINAL FOR WIDE-BAND COMMUNICATIONS TO REMOTE SITES. 
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■ STUDY; FINAL REPORT 


This is the 'list of 15 documents that constitute the Final Report of 
this Study. At this time all . documents have been completed and distributed 
by the COR with the exception of Volumes I, II-E, II-F and II -G. Volumes 
II-E and II-F have been completed and reviewed by the COR. Volumes I and 
1 1-6 will be completed and distributed by 'completion of the Study schedule 
{•idth month) . 
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STUDY FINAL REPORT 


VOLUME I - FINAL SUMMARY REPORT 

VOLUME II-A - STUDY TASK a - 1 ,0 FLIGHT CONTROL FUNCTIONS 

VOLUME II-B - STUDY TASK b - 2.0 TYPES AND LOCATIONS OF PARTIES INVOLVED 

VOLUME II-C - STUDY TASK c - GENERAL, 3.0 INVESTIGATION OF PRESENT/PLANNED 

NASA-WIDE FACILITIES AVAILABLE 

VOLUME II-C - STUDY TASK c - APPENDIX A - NASA/ ARC CAPABILITIES 

VOLUME II-C - STUDY TASK c - APPENDIX B - NASA/GSFC CAPABILITIES 

VOLUME II-C - STUDY TASK c - APPENDIX C - NASA/JPL CAPABILITIES ' 

VOLUME II-C - STUDY TASK c - APPENDIX D - NASA/ JSC CAPABILITIES 

VOLUME II-C - STUDY TASK c - APPENDIX E - NASA/KSC CAPABILITIES 

VOLUME II-C - STUDY TASK c - APPENDIX F - NASA/LaRC' CAPABILITIES 

VOLUME II-C - STUDY TASK c - APPENDIX G - NASA/MSFC CAPABILITIES 

VOLUME II-D - study TASK d - 4.0 ALLOCATION OF FLIGHT CONTROL FUNCTIONS 

VOLUME II-E - STUDY TASK e - 5.0 OPERATIONAL INFORMATION FLOW AND PROCESSING 

VOLUME II-F - STUDY TASK f - 6.0 DEFINITION OF- SYSTEM CONCEPTS 

VOLUME II-G ~ STUDY TASK g - 7.0 RESOURCES MODEL AND ESTIMATES 
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